(19) 



(12) 



J 



Europalsches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



(id EP 1 526 424 B1 

EUROPEAN PATENT SPECIFICATION 



(45) Date of publication and mention 
of the grant of the patent: 
10.12.2008 Bulletin 2008/50 



(51) IntCI.: 

G06F 21/00 ( 200601 > 



G06F21/04< 200601 > 



(21 ) Application number: 04020876.1 

(22) Date of filing: 02.09.2004 



(54) Providing a graphical user interface in a system with a high-assurance execution environment 

Bereitstellung einer grafischen Benutzerschnittstelle in einem System mit gesicherter 
Ausfuhrungsumgebung 

Fourniture d'une interface utilisateur graphique dans un systeme avec un environnement d'execution 
securise 



(84) Designated Contracting States: 

AT BE BG CH CY CZ DE DK EE ES Fl FR GB GR 
HU IE IT LI LU MC NL PL PT RO SE SI SK TR 

(30) Priority: 23.10.2003 US 691759 

(43) Date of publication of application: 
27.04.2005 Bulletin 2005/17 

(73) Proprietor: MICROSOFT CORPORATION 
Redmond, Washington 98052 (US) 

(72) Inventors: 

• Willman, Bryan, M. 
Redmond 

Washington 98052 (US) 

• Chew, Christine, M. 
Redmond 

Washington 98052 (US) 

• Avraham, Idan 
Redmond 

Washington 98052 (US) 

• Roberts, Paul, C. 
Redmond 

Washington 98052 (US) 

(74) Representative: Grunecker, Kinkeldey, 
Stockmair & Schwanhausser 
Anwaltssozietat 
Leopoldstrasse 4 

80802 Munchen (DE) 



CD 

CM 

CM 

m 



CL 
LU 



(56) References cited: 
US-A- 5 590 266 

• EPSTEIN J ET AL: "User interface for a high 
assurance, windowing system" COMPUTER 
SECURITY APPLICATIONS CONFERENCE, 1993. 
PROCEEDINGS., NINTH ANNUAL ORLANDO, FL, 
USA 6-10 DEC. 1993, LOS ALAMITOS, CA, USA, 
IEEE COMPUT. SOC, 6 December 1993 

(1 993-1 2-06), pages 256-264, XP01 0096756 ISBN : 
0-8186-4330-7 

• ZISHUANG YE, SEAN SMITH : "Trusted Paths for 
Browsers: An Open-Source Solution to Web 
Spoofing" TECHNICAL REPORT TR2002-418, 
[Online] 4 February 2002 (2002-02-04), 
XP002329977 DEPATMENT OF COMPUTER 
SCIENCE DARTMOUTH COLLEGE Retrieved 
from the Internet: URL:http: 

//www. eg i sec u rity.com/lib/tr41 8. p df> [retrieved 
on 2005-05-30] 

• "AT WINHEC, MICROSOFT DISCUSSES DETAILS 
OF NEXT-GENERATION SECURE COMPUTING 
BASE"[Online] 7 May 2003 (2003-05-07), 
XP002302516 Retrieved from the Internet: URL: 
www.microsoft.com> [retrieved on 2004-10-26] 



Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent 
Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the 
Implementing Regulations. Notice of opposition shall not be deemed to have been filed until the opposition fee has been 
paid. (Art. 99(1) European Patent Convention). 



Printed by Jouve, 75001 PARIS (FR) 



1 



EP 1 526 424 B1 



2 



Description 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to the 
field of computer security. More particularly, the invention 
relates to the use of plural execution environments (e.g., 
operating systems) on a single computing device with a 
graphical user interface which allows graphical user in- 
terface elements to be owned by processes in each of 
the plural execution environments. 

BACKGROUND OF THE INVENTION 

[0002] In modem computing, many tasks which can be 
performed on a computer require some level of security. 
In order to provide a level of security, there are several 
options. One is to perform all secure applications on a 
computer which is completely separate from any possibly 
insecure elements, or to use a virtual machine monitor 
(VMM) to allow complete separation between two exe- 
cution environments (e.g. operating systems) running on 
a single computer system. However, this may be imprac- 
tical. There may be a need, for cost or convenience rea- 
sons, for a secure execution environment to share re- 
sources with applications with unassured security, and 
those applications and those resources may be vulner- 
able to an attacker. Additionally, where a VMM is used, 
since a VMM requires full virtualization of the machine 
and all of its devices (thereby requiring that the VMM 
provide its own device driver for every possible device), 
a VMM is not well suited to an open architecture machine 
in which an almost limitless variety of devices can be 
added to the machine. 

[0003] One way to provide the ability to share resourc- 
es among two execution environments is to provide a 
computer system in which there is one "main" operating 
system that controls most processes and devices on a 
machine, and where a second operating system also ex- 
ists. This second operating system is a small, limited- 
purpose operating system alongside the main operating 
system which performs certain limited tasks. One way to 
make an operating system "small" or "limited-purpose" 
is to allow the small operating system to borrow certain 
infrastructure (e.g., the scheduling facility, the memory 
manager, the device drivers, etc.) from the "main" oper- 
ating system. Since a VMM effectively isolates one op- 
erating system from another, this sharing of infrastructure 
is not practical using a VMM. 

[0004] Certain other techniques allow operating sys- 
tems to exist side-by-side on the same machine without 
the use of a VMM. One such technique is to have one 
operating system act as a "host" for the other operating 
system. (The operating system that the "host" is hosting 
is sometimes called a "guest.") In this case, the host op- 
erating system provides the guest with resources such 
as memory and processor time. Another such technique 
is the use of an "exokernel." An exokernel manages cer- 



tain devices (e.g., the processor and the memory), and 
also manages certain types of interaction between the 
operating systems, although an exokernel -unlike a VMM 
- does not virtualize the entire machine. Even when an 

5 exokernel is used, it may be the case that one operating 
system (e.g., the "main" operating system) provides 
much of the infrastructure for the other, in which case the 
main operating system can still be referred to as the 
"host," and the smaller operating system as the "guest." 

10 Both the hosting model and the exokernel model allow 
useful types of interaction between operating systems 
that support sharing of infrastructure. 
[0005] Thus, these techniques can be used to provide 
a computer system with at least two execution environ- 

15 ments. One of these may be a "high-assurance" operat- 
ing system, referred to herein as a "nexus." A high-as- 
surance operating system is one that provides a certain 
level of assurance as to its behavior. For example, a nex- 
us might be employed to work with secret information 

20 (e.g., cryptographic keys, etc.) that should not be di- 
vulged, by providing a curtained memory that is guaran- 
teed not to leak information to the world outside of the 
nexus, and by permitting only certain certified applica- 
tions to execute under the nexus and to access the cur- 

25 tained memory. 

[0006] In a computer system with two execution envi- 
ronments, one of which is a nexus, it may be desirable 
for the nexus to be the guest operating system, and a 
second operating system, not subject to the same level 

30 of assurance as to behavior, to be the host operating 
system. This allows the nexus to be as small as possible. 
A small nexus allows a higher level of confidence in the 
assurance provided by the nexus. Therefore operating 
system functions are run by the host operating system. 

35 [0007] One such operating system which may be run 
by the host operating system is a windowing system. 
When using a windowing system, a user's display will be 
populated with windows, areas on the screen which dis- 
play information from an application. An application may 

40 have one or more windows. 

[0008] When the windowing system is run by the host 
operating system, rather than by the nexus, it is vulner- 
able to attack. One such possible attack is known as a 
spoof. A spoof is an attack in which the user is led to 

45 believe that some hardware, system software, applica- 
tion or agent software, or a given window, is a trustworthy 
entity, even though it is not. The attacker is spoofing a 
trustworthy entity. This can be used to steal user creden- 
tials, or to capture other data of a sensitive nature entered 

50 by a user who thinks that the user is using a highly as- 
sured entity. 

[0009] For example, in a system in which the nexus 
runs a banking program with a log-in screen, an attacker 
may write a program which runs on the host operating 
55 system, and displays a window which looks exactly like 
the log-in screen of the banking program. When the user 
is fooled by this spoof window, the user will enter infor- 
mation into the spoof window. This information is cap- 
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tured by the attacker and may then be used by the at- 
tacker without the knowledge of the user. 
[0010] The windowing system is also vulnerable to an 
attack known as a snooker. In a snooker attack, the at- 
tacker changes the user display to make it appear to a 
user that the system is secure, when it is not. For exam- 
ple, a computer system may include the ability for a user 
to lock the system, or to allow the computer to sleep or 
hibernate. A snooker attack, in this case, would simulate 
the screen displayed when the system is locked, asleep, 
or hibernating. When the user turns their attention away, 
thinking that the system is inactive and secure, the at- 
tacker makes unauthorized use of the system. 
[0011] Generally, whatever pattern of pixels a legiti- 
mate nexus-side program or functioning system can pro- 
duce on the monitor, an attacking program on the host- 
side can imitate. However, in order to maintain the high 
assurance nature of the nexus, a user must be able to 
distinguish a legitimate nexus-side user interface graphic 
element from a fake one. 

[0012] In their article "User Interface for a High Assur- 
ance Windowing System" (Computer Security Applica- 
tions Conference, 1993. Proceedings., Ninth Annual), 
Epstein and Pascale describe graphical user interfaces 
which can accommodate multiple levels of security. The 
authors suggest having each of the windows sharing the 
display include indicators of the corresponding level of 
security, such as window labels (e.g., "top secret") or win- 
dow borders in reserved colors. In conjunction with tiling 
restrictions preventing total or partial overlap of windows, 
such indicators can be useful for preventing spoofing of 
a window's security level. It is to be inferred, however, 
thatsaid indicators are to be chosen in a consistent, easy- 
to-guess way, which would give malicious windows the 
opportunity to spoof secure ones by mimicking their se- 
curity indicators. 

[0013] In view of the foregoing there is a need for a 
system that overcomes the drawbacks of the prior art. 

SUMMARY OF THE INVENTION 

[0014] In one embodiment, data displayed on a display 
for a system including a secured execution environment 
(nexus) and a second execution environment (host) is 
secured using a combination of several techniques. 
Graphical user interface elements, such as windows, 
which are associated with a process running on the nexus 
are displayed without overlap from other graphical user 
interface elements. 

[001 5] Additionally, a nexus-user secret is maintained, 
which is displayed in the graphical user interface ele- 
ment. This display can occur continuously or, among oth- 
er alternatives, on request. Additionally, window decora- 
tions may be coordinated, in color or in graphics infor- 
mation being displayed, in order to link together in a us- 
er's mind the secured windows and thus more clearly 
highlight impostor windows. These decorations can be 
changed at certain intervals, upon request, or when a 



system event triggers the change. 
[001 6] Where a shadow window is maintained for cor- 
responding nexus windows, private title information may 
be used for the nexus window while a public title is used 
5 in the shadow window. This allows the nexus process 
which sets the titles to choose what information will be 
given to the possibly insecure shadow window. 
[0017] Other features of the invention are described 
below. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0018] The foregoing summary, as well as the following 
detailed description of preferred embodiments, is better 

15 understood when read in conjunction with the appended 
drawings. For the purpose of illustrating the invention, 
there is shown in the drawings exemplary constructions 
of the invention; however, the invention is not limited to 
the specific methods and instrumentalities disclosed. In 

20 the drawings: 

FIG. 1 isablockdiagramof an exemplary computing 
environment in which aspects of the invention may 
be implemented; 
25 FIG. 2 is a blockdiagram of two exemplary execution 
environments that maintain some interaction with 
each other and some separation from each other; 
FIG. 3 (a) is a block diagram of a display; 
FIG. 3(b) is a block diagram of a display according 
30 to one embodiment of the invention; 

FIG. 4 is a flow diagram of a method for maintaining 
the security of data displayed on a display; 
FIG. 5 is a flow diagram of a method for maintaining 
the security of data displayed on a display; 
35 FIG. 6 is a block diagram of a display according to 
one embodiment of the invention; and 
FIG. 7 is a flow diagram of a method for maintaining 
the security of data displayed on a display; 
FIG. 8 is a flow diagram of a method for maintaining 
40 the security of data displayed on a display. 

DETAILED DESCRIPTION OF THE INVENTION 

Overview 

45 

[001 9] When two execution environments, such as op- 
erating systems, run side-by-side on a single machine, 
where one of the environments is a high-assurance ex- 
ecution environment which is held to certain standards 

50 of security, it may be important for a user to discern which 
graphical user interface elements being displayed are 
associated with processes running on the high-assur- 
ance operating system. As discussed above, an attacker 
displaying a graphical Ul element via the host side (non 

55 high-assurance) execution environment may attempt to 
convince a user that a graphical user interface element 
that is a Ul element arising from a high assurance proc- 
ess. In order to prevent such attacks, the present inven- 
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tion provides techniques that allow a user to discern 
which graphical user interface elements originate in the 
high-assurance execution environment. 

Exemplary Computing Arrangement 

[0020] FIG. 1 shows an exemplary computing environ- 
ment in which aspects of the invention may be imple- 
mented. The computing system environment 1 00 is only 
one example of a suitable computing environment and 
is not intended to suggest any limitation as to the scope 
of use or functionality of the invention. Neither should the 
computing environment 1 00 be interpreted as having any 
dependency or requirement relating to any one or com- 
bination of components illustrated in the exemplary op- 
erating environment 100. 

[0021 ] The invention is operational with numerous oth- 
er general purpose or special purpose computing system 
environments or configurations. Examples of well known 
computing systems, environments, and/or configura- 
tions that may be suitable for use with the invention in- 
clude, but are not limited to, personal computers, server 
computers, hand-held or laptop devices, multiprocessor 
systems, microprocessor-based systems, set top boxes, 
programmable consumer electronics, network PCs, min- 
icomputers, mainframe computers, embedded systems, 
distributed computing environments that include any of 
the above systems or devices, and the like. 
[0022] The invention may be described in the general 
context of computer-executable instructions, such as 
program modules, being executed by a computer. Gen- 
erally, program modules include routines, programs, ob- 
jects, components, data structures, etc. that perform par- 
ticular tasks or implement particular abstract data types. 
The invention may also be practiced in distributed com- 
puting environments where tasks are performed by re- 
mote processing devices that are linked through a com- 
munications network or other data transmission medium. 
In a distributed computing environment, program mod- 
ules and other data may be located in both local and 
remote computer storage media including memory stor- 
age devices. 

[0023] With reference to FIG. 1 , an exemplary system 
for implementing the invention includes a general pur- 
pose computing device in the form of a computer 1 10. 
Components of computer 110 may include, but are not 
limited to, a processing unit 120, a system memory 130, 
and a system bus 1 21 that couples various system com- 
ponents including the system memory to the processing 
unit 1 20. The processing unit 1 20 may represent multiple 
logical processing units such as those supported on a 
multi-threaded processor. The system bus 121 may be 
any of several types of bus structures including a memory 
bus or memory controller, a peripheral bus, and a local 
bus using any of a variety of bus architectures. By way 
of example, and not limitation, such architectures include 
Industry Standard Architecture (ISA) bus, Micro Channel 
Architecture (MCA) bus, Enhanced ISA (EISA) bus, Vid- 



eo Electronics Standards Association (VESA) local bus, 
and Peripheral Component Interconnect (PCI) bus (also 
known as Mezzanine bus). The system bus 121 may also 
be implemented as a point-to-point connection, switching 

5 fabric, or the like, among the communicating devices. 
[0024] Computer 110 typically includes a variety of 
computer readable media. Computer readable media 
can be any available media that can be accessed by com- 
puter 110 and includes both volatile and nonvolatile me- 

10 dia, removable and non-removable media. Byway of ex- 
ample, and not limitation, computer readable media may 
comprise computer storage media and communication 
media. Computer storage media includes both volatile 
and nonvolatile, removable and non-removable media 

15 implemented in any method or technology for storage of 
information such as computer readable instructions, data 
structures, program modules or other data. Computer 
storage media includes, but is not limited to, RAM, ROM, 
EEPROM, flash memory or other memory technology, 

20 CDROM, digital versatile disks (DVD) or other optical disk 
storage, magnetic cassettes, magnetic tape, magnetic 
disk storage or other magnetic storage devices, or any 
other medium which can be used to store the desired 
information and which can accessed by computer 1 10. 

25 Communication media typically embodies computer 
readable instructions, data structures, program modules 
or other data in a modulated data signal such as a carrier 
wave or other transport mechanism and includes any in- 
formation delivery media. The term "modulated data sig- 

30 rial" means a signal that has one or more of its charac- 
teristics set or changed in such a manner as to encode 
information in the signal. By way of example, and not 
limitation, communication media includes wired media 
such as a wired network or direct-wired connection, and 

35 wireless media such as acoustic, RF, infrared and other 
wireless media. Combinations of any of the above should 
also be included within the scope of computer readable 
media. 

[0025] The system memory 130 includes computer 

40 storage media in the form of volatile and/or nonvolatile 
memory such as read only memory (ROM) 131 and ran- 
dom access memory (RAM) 132. A basic input/output 
system 133 (BIOS), containing the basic routines that 
help to transfer information between elements within 

45 computer 1 1 0, such as during start-up, is typically stored 
in ROM 131. RAM 1 32 typically contains data and/or pro- 
gram modules that are immediately accessible to and/or 
presently being operated on by processing unit 120. By 
way of example, and not limitation, FIG. 1 illustrates op- 

50 erating system 134, application programs 135, other pro- 
gram modules 136, and program data 137. 
[0026] The computer 110 may also include other re- 
movable/non-removable, volatile/nonvolatile computer 
storage media. By way of example only, FIG. 1 illustrates 

55 a hard disk drive 140 that reads from or writes to non- 
removable, nonvolatile magnetic media, a magnetic disk 
drive 151 that reads from or writes to a removable, non- 
volatile magnetic disk 152, and an optical disk drive 155 



4 



7 



EP 1 526 424 B1 



8 



that reads from or writes to a removable, nonvolatile op- 
tical disk 1 56, such as a CD ROM or other optical media. 
Other removable/non-removable, volatile/nonvolatile 
computer storage media that can be used in the exem- 
plary operating environment include, but are not limited 
to, magnetic tape cassettes, flash memory cards, digital 
versatile disks, digital video tape, solid state RAM, solid 
state ROM, and the like. The hard disk drive 141 is typ- 
ically connected to the system bus 121 through a non- 
removable memory interface such as interface 140, and 
magnetic disk drive 151 and optical disk drive 155 are 
typically connected to the system bus 121 by a removable 
memory interface, such as interface 150. 
[0027] The drives and their associated computer stor- 
age media discussed above and illustrated in FIG. 1 , pro- 
vide storage of computer readable instructions, data 
structures, program modules and other data for the com- 
puter 110. In FIG. 1 , for example, hard disk drive 141 is 
illustrated as storing operating system 144, application 
programs 1 45, other program modules 1 46, and program 
data 147. Note that these components can either be the 
same as or different from operating system 134, appli- 
cation programs 135, other program modules 136, and 
program data 137. Operating system 144, application 
programs 1 45, other program modules 1 46, and program 
data 147 are given different numbers here to illustrate 
that, at a minimum, they are different copies. A user may 
enter commands and information into the computer 20 
through input devices such as a keyboard 1 62 and point- 
ing device 1 61 , commonly referred to as a mouse, track- 
ball or touch pad. Other input devices (not shown) may 
include a microphone, joystick, game pad, satellite dish, 
scanner, or the like. These and other input devices are 
often connected to the processing unit 120 through a 
user input interface 160 that is coupled to the system 
bus, but may be connected by other interface and bus 
structures, such as a parallel port, game port or a univer- 
sal serial bus (USB). A monitor 1 91 or other type of dis- 
play device is also connected to the system bus 121 via 
an interface, such as a video interface 190. In addition 
to the monitor, computers may also include other periph- 
eral output devices such as speakers 197 and printer 
1 96, which may be connected through an output periph- 
eral interface 1 90. 

[0028] The computer 1 1 0 may operate in a networked 
environment using logical connections to one or more 
remote computers, such as a remote computer 1 80. The 
remote computer 180 may be a personal computer, a 
server, a router, a network PC, a peer device or other 
common network node, and typically includes many or 
all of the elements described above relative to the com- 
puter 110, although only a memory storage device 181 
has been illustrated in FIG. 1. The logical connections 
depicted in FIG. 1 include a local area network (LAN) 1 71 
and a wide area network (WAN) 1 73, but may also include 
other networks. Such networking environments are com- 
monplace in offices, enterprise-wide computer networks, 
intranets and the Internet. 



[0029] When used in a LAN networking environment, 
the computer 1 1 0 is connected to the LAN 1 71 through 
a network interface or adapter 1 70. When used in a WAN 
networking environment, the computer 1 10 typically in- 
5 eludes a modem 172 or other means for establishing 
communications over the WAN 173, such as the Internet. 
The modem 1 72, which may be internal or external, may 
be connected to the system bus 121 via the user input 
interface 160, or other appropriate mechanism. In a net- 
10 worked environment, program modules depicted relative 
to the computer 1 10, or portions thereof, may be stored 
in the remote memory storage device. By way of exam- 
ple, and not limitation, FIG. 1 illustrates remote applica- 
tion programs 1 85 as residing on memory device 181. It 
15 will be appreciated that the network connections shown 
are exemplary and other means of establishing a com- 
munications link between the computers may be used. 

Plural Computing Environments on a Single Machine 

20 

[0030] As previously described, it is known in the art 
that two operating systems can execute side-by-side on 
a single computing device. One problem that the present 
invention can be used to address is how to provided some 
25 level of separation between two operating system, while 
still providing for some level of interaction between the 
two operating systems. 

[0031] FIG. 2 shows a system in which two operating 
systems 134(1) and 134(2) execute on a single computer 

30 no. Some type of logical separation 202 exists between 
operating systems 1 34(1 ) and 1 34(2), such that a certain 
amount of interaction 204 is permitted between operating 
systems 134(1) and 134(2), while still allowing at least 
one of the operating systems to be protected against 

35 events that originate in the other operating system. In the 
example of FIG. 2, operating system 134(1) is a host 
operating system, and operating system 1 34 (2) is a guest 
operating system, such as a "nexus" as described above. 
As previously noted, when operating system 134(2) is a 

40 nexus, it is desirable to construct separation 202 such 
that operating system 134(2) can interact with operating 
system 134(1) in order to borrow operating system 134 

(1) 's infrastructure, while still allowing operating system 
134(2) to protect itself from actions (either malicious or 

45 innocent) that arise at operating system 134(1) and might 
cause operating system 134(2) to behave in a manner 
contrary to its behavioral specifications. (It will be under- 
stood, however, that the invention is not limited to the 
case where operating system 134(2) is a nexus.) 

50 [0032] The separation 202 between operating systems 
134(1) and 134(2) may, optionally, be enforced with the 
aid of a security monitor. A security monitor is a compo- 
nent external to both operating systems 134(1) and 134 

(2) , which provides some security services that may be 
55 used to protect operating system 134(2) from operating 

system 134(1). For example, a security monitor may con- 
trol access to certain hardware, may manage the use of 
memory (to give operating system 134(2) exclusive use 
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of some portions of memory), or may facilitate the com- 
munication of data from operating system 134(1) to op- 
erating system 1 34(2) in a secure way. It should be noted 
that the use of a security monitor represents one model 
of how operating system 134(2) can be protected from 
operating system 134(1), although the use of a security 
monitor is not required. As another example, operating 
system 134(2) could include all of the functionality nec- 
essary to protect itself from operating system 134(1). 
[0033] It should be noted that FIG. 2 shows operating 
system 134(1) as a "host" and operating system 134(2) 
as a "guest." In general, this characterization refers to 
the fact that, in these examples, operating system 134 

(1) provides certain operating system infrastructure that 
is used by both operating systems 134(1) and 134(2) 
(e.g., device drivers, scheduling, etc.), and operating sys- 
tem 134(2) is a "guest" in the sense that it preferably 
lacks this infrastructure but rather uses the infrastructure 
of operating system 134(1). However, it should be noted 
that the parameters of what makes an operating system 
a "host" or a "guest" are flexible. Moreover, it should be 
noted that traditional concepts of "host" and "guest" op- 
erating systems presume that the host needs to protect 
itself from actions of the guest. In the example of FIGS. 
2, however, guest operating system 134(2) is presumed 
to be a high-assurance operating system that needs to 
protect itself from host operating system 134(1). In the 
examples that follow, we shall generally refer to operating 
system 134(1) as the "host" and operating system 134 

(2) as the "guest" or "nexus" for the purpose of distin- 
guishing between them. It should be appreciated that the 
techniques described herein can be applied to the inter- 
action of any two or more operating systems running on 
the same machine (or even on the same set of connected 
machines). 

Providing A Graphical User Interface With Plural Com- 
puting Environments On A Single Machine 

[0034] When a user interacts with programs on a com- 
puter system containing a high-assurance operating sys- 
tem, the user does so by means of a user input device, 
such as mouse 1 61 or keyboard 1 62 (from Figure 1 ). As 
discussed above, allowing the windowing system run- 
ning on host operating system 134(1) control the desti- 
nation of the stream of input events may allow an attack 
using a compromised host operating system or applica- 
tion. A window or other graphical user interface element 
may be displayed by a host-side process to the user, 
which may attempt to imitate a legitimate nexus-side 
process, running on nexus operating system 134(2). 
Therefore, according to one embodimentof the invention, 
several techniques for protecting the integrity and iden- 
tifiableness of legitimate host-side windows and other 
graphical user interface elements are implemented. In 
various embodiments of the invention, any one or all of 
these techniques are implemented together. 



Obscuration and Show-Through 

[0035] Where both host-side and nexus-side process- 
es can display graphics, such as windows and other user 
5 interface elements, on a display, an attack can be ac- 
complished by obscuring all or part of a legitimate nexus- 
side process graphic with a host-side process graphic. 
Figure 3(a) is a block diagram of a display. In Figure 3 
(a), on display 300, nexus graphics 310 are graphics 
10 owned by nexus processes, running on the nexus oper- 
ating system 134(2). Host graphics 320 are graphics 
owned by host processes, running on the host operating 
system 134(1). As shown in Figure 3 (a), where host 
graphics 320 are allowed to be displayed on top of nexus 
15 graphics 310, the nexus graphics may be obscured by 
the host graphics 320. In this case, an attack may be 
mounted by obscuring some or all of nexus graphic 31 0 
with a host graphic 320. Additionally, if the nexus graphic 
31 0 overlays a host graphic 320 but is partially transpar- 
20 ent, the host graphic 320 may be used to change the 
appearance of the nexus graphic 31 0 in a confusing way. 
[0036] In one embodiment, such attacks are prevented 
by preventing the all nexus graphics 31 0 from being ob- 
scured, and prohibiting any show-through in nexus 
25 graphics 310. Thus, for the situation shown in Figure 3 
(a), the nexus graphics 310 would not be allowed to be 
obscured. Figure 3(b) is an illustration of the prohibition 
on obscuration of nexus graphic31 0. In Figure 3(b), each 
of the two nexus graphics 310 are fully shown, and no 
30 overlap by a host graphic 320 of a nexus graphic 31 0 is 
permitted. In addition, in one embodiment, no transpar- 
ency (either full transparency or partial transparency) is 
permitted in a nexus graphic 310. 
[0037] In one embodiment, in order to prevent similar 
35 attacks from one nexus-side process on another, nexus 
graphics 310 may not overlap. In a windowing system, 
one embodiment allows one exception to this - the mouse 
cursor, which may be drawn by a nexus-side process 
when being displayed over a nexus graphic 31 0, may be 
40 allowed to overlap a nexus-side graphic 31 0. 

[0038] In another embodiment, if one nexus-side proc- 
ess owns two or more user interface graphic elements, 
for example two windows or a window and a dialog box, 
no security issue is implicated in allowing these to over- 
45 lap. Thus, one commonly-owned user interface graphic 
element is allowed to overlap another commonly-owned 
user interface graphic element owned by a nexus proc- 
ess. In still another embodiment, top-level graphic Ul el- 
ements which are commonly-owned are not permitted to 
50 overlap, however, a top-level Ul element may be over- 
lapped by a child Ul element of that top-level Ul element. 
For example, in this embodiment, a dialog box which is 
a child Ul element of a top-level window can overlap that 
window. 

55 [0039] In one embodiment, in order to verify which user 
interface graphic elements are nexus-side user interface 
graphic elements, a hypothecated user interaction is pro- 
vided which removes all non-nexus-side user interface 
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graphic elements from the screen. A hypothecated user 
interaction is a user interaction which, in the context of 
the computer system, will always result in a specific con- 
sequence. Thus, when the secure display hypothecated 
user interaction, for example, a keystroke combination, 
occurs, the entire display is cleared, with the exception 
of nexus-side user interface graphic elements. 
[0040] Figure 4 is a flow diagram of this method. In 
step 400, a nexus graphical user interface element im- 
age, associated with a process running on the secured 
execution environment (nexus agent) is stored. In step 
410, the nexus graphical user interface element image 
is displayed completely, unobscured by any host user 
interface elements. In other embodiments, no graphical 
user interface elements (host or user) other than those 
associated with the process can obscure the nexus 
graphical user interface element. 

Secret Sharing 

[0041] In one embodiment, in order to prevent the 
spoofing attack described above, a secret is displayed 
which is hidden from the host-side. No process on the 
host side can access the secret, and therefore if a window 
or other graphic user interface element can display the 
secret, it is a host-side graphic user interface element. 
[0042] In one embodiment, a secret is communicated 
to the nexus by the user. This nexus-user secret may be 
communicated to the nexus at trust-initialization time, for 
example when passwords are set by the user. The graph- 
ic user interface element may either display the nexus- 
user secret at all times or may display the nexus-user 
secret when challenged. 

[0043] A trusted window manager on the nexus side 
controls the display of graphic user interface elements 
by processes on the nexus side. This trusted window 
manager is also responsible for window decorations, 
such as borders and titles of windows. In one embodi- 
ment, the nexus-user secret is not generally shared with 
processes in the nexus. It is, however, displayed in the 
window decoration by the trusted window manager. In 
an alternate embodiment, the nexus-user secret is dis- 
played when a user requests it from the window. This 
request may be made on the window in focus through a 
hypothecated user interaction. For example, a specific 
combination of keystrokes may be the hypothecated user 
interaction which causes the window in focus to display 
the nexus-user secret. Alternatively, a window may in- 
clude a drop down menu or activation area which, when 
selected by the mouse or by keystrokes causes a valid 
nexus graphic 310 to display the nexus-user secret. 
[0044] The nexus-user secret may be an image or a 
phrase. An image can be a useful nexus-user secret, 
because they are easily identified by the user and hard 
to describe. If the image selected by the user for use as 
the nexus-user secret is, for example, a photograph of 
the user's dog in front of the user's house, the photograph 
may be described by an attacker who views the image 



on the user's screen, however, even with that information 
an attacker would have difficulty recreating the image or 
finding a copy of it. 

[0045] Figure 5 is a flow diagram of this method. In 
5 step 500, a nexus-user secret associated with the nexus 
is stored. In step 51 0, the nexus-user secret element im- 
age is displayed as part of a nexus graphical user inter- 
face element. 

10 Continual Secret Permutation 

[0046] As described, in one embodiment a trusted win- 
dow manager is the intermediary through which all nex- 
us-side processes display their user interface graphic el- 

15 ements, and the trusted window manager is solely re- 
sponsible for the window decoration, such as borders, 
on user interface graphic elements. In one embodiment, 
the window decoration includes a continually-updated 
short term secret. This continually updated secret is not 

20 accessible to non-nexus windows, and can thus be used 
to identify a non-host window. 

[0047] For example, where the border of each nexus 
user interface graphic element is a specific color, and 
that color changes once every 15 seconds, it will be ob- 
25 vious to a user when a given window border does not 
match other nexus user interface graphic elements that 
that window is not a nexus-side user interface graphic 
elements. Other possible continually updated secrets 
may include: small graphics, combinations of icons, 
30 glyphs, or characters displayed in the window decoration, 
or hexadecimal or numeric strings. Any piece of informa- 
tion which can be visually compared with discrepancies 
noted fairly easily by a user might be used. 
[0048] In one embodiment, a nexus system user inter- 
35 face area is maintained on the display 300 whenever a 
nexus graphic 310 is displayed. This user interface area 
lists information regarding the nexus graphics 310 being 
displayed. For example, the user interface area may list 
the number of nexus graphics 310 being displayed, or 
40 the names of the nexus graphics 310 being displayed 
(e.g. window titles.) The shared secret in the decoration 
of the nexus graphics 31 0 is also displayed in the nexus 
system user interface area. Figure 6 is a block diagram 
of a display according to one embodiment of the inven- 
45 tion. In Figure 6, a series consisting of three glyphs 
("—♦□") is displayed in window decoration 610 of each 
nexus graphic 310 on the display 300. A nexus system 
interface area 600 is also displayed, which includes the 
same set of three glyphs. This allows easy user confir- 
50 mation that a window is being displayed by a nexus-side 
process. 

[0049] While the changing of the secret may be time- 
based, such as a colored border that changes every 15 
seconds, as described above, in other embodiments, the 
55 secret permutes when the user requests it, through a 
hypothecated user interaction, or when a system event 
such as the change of focus from one window to another 
occurs. 
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[0050] Figure 7 is a flow diagram of this method. In 
step 700, at least two nexus graphical data elements are 
accepted. In a windowing system, these, along with the 
window decorations, will constitute a window image. In 
step 710, two nexus graphical user interface elements 
(e.g. windows) are displayed - each comprising one of 
the graphical data elements in addition to decoration 
which is common to each window. 

Window Titles - Public and Private 

[0051] As described, a trusted window manager can 
be used as an intermediary through which all nexus-side 
processes display their user interface graphic elements. 
However, a host-side window manager can be used to 
manage the display of host-side processes' user inter- 
face graphic elements. In one embodiment, for each nex- 
us-side user interface graphic element (such as nexus 
graphic 310) a corresponding shadow graphic user in- 
terface elements is maintained by the host-side window 
manager. This allows the host-side window manager to 
recognize that certain areas of the display 300 are being 
used by nexus graphics 310. When obscuration and 
show-through are prohibited, as described above, this 
may be useful information for the host-side window man- 
ager, so windows which should be visible are not placed 
in these areas. However, only limited information about 
nexus graphics 31 0 should be available in the host-side. 
[0052] In one embodiment, therefore, the trusted win- 
dow manager allows a nexus agent (a process running 
on the nexus) to set two titles for each window or other 
user interface graphic element. One title, the private title, 
is passed to the trusted window manager and used for 
window management functions and for display in nexus 
graphic 31 0. This private title is not shared by the trusted 
window manager with any host-side processes or with 
any nexus-side processes other than the nexus agent 
which owns the window (or other element.) 
[0053] In addition to the private title, the nexus agent 
can also specify a public title. This public title may be 
shared with the host-side, including the host-side window 
manager. The public title may be used by the host-side 
window manager as the title for the shadow window. In 
this way, the host-side window manager can reference 
the window using the public title, which is selected in 
order to be understandable to the user without including 
information which may breach confidentiality. Thus, 
where the host-side window manager allows a user to 
select a window to focus on from a list of windows, the 
public title, associated with the shadow window, is listed 
as an option to select. When the shadow window is se- 
lected, the associated trusted window will be activated, 
and the nexus agent associated with the associated trust- 
ed window will become the focus of user input. 
[0054] Figure 8 is a flow diagram of this method. In 
step 800, public title information and private title informa- 
tion is stored for a nexus graphical user interface element 
associated with a nexus agent. In step 810, the private 



title information is used for window management func- 
tions of the trusted window manager. In step 820, the 
public title information is provided to the host for use on 
the host-side. 

5 

Conclusion 

[0055] It is noted that the foregoing examples have 
been provided merely for the purpose of explanation and 
10 are in no way to be construed as limiting of the present 
invention. While the invention has been described with 
reference to various embodiments, it is understood that 
the words which have been used herein are words of 
description and illustration, rather than words of limita- 
15 tions. Further, although the invention has been described 
herein with reference to particular means, materials and 
embodiments, the invention is not intended to be limited 
to the particulars disclosed herein; rather, the invention 
extends to all functionally equivalent structures, methods 
20 and uses, such as are within the scope of the appended 
claims. 



Claims 

25 

1. A method for maintaining the security of data dis- 
played on a display for a system comprising a se- 
cured execution environment and a second execu- 
tion environment, comprising: 

30 

storing an image of at least one first graphical 
user interface element, associated with a first 
process running on said secured execution en- 
vironment; and 

35 displaying said first graphical user interface el- 

ement, including a first secret associated with 
said secured execution environment, on said 
display completely on a display, such that no 
part of said first graphical user interface element 

40 is obscured by a second graphical user interface 

element associated with said second execution 
environment on said display, said first secret be- 
ing communicated to said secured execution en- 
vironment by a user and not being accessible 

45 by a second process on said second execution 

environment. 

2. The method of claim 1 , where said step of displaying 
saidfirstgraphical user interface element comprises: 

50 

ensuring that said first graphical user interface 
element contains no areas of transparency. 

3. The method of claim 1 , where said step of displaying 
55 said first graphical user interface element on a dis- 
play comprises displaying said first graphical user 
interface elementsuch that no part of said firstgraph- 
ical user interface element is obscured by said sec- 
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ond graphical user interface element, which is asso- 
ciated with a third process running on said secured 
execution environment. 

4. The method of claim 1 , further comprising: 

displaying only said first graphical user interface 
element on said display upon receipt of a user 
secure display indication. 

5. The method of claim 1 , further comprising: 

accepting a secret-display indication; from a us- 
er; and 

displaying said first secret in response to accept- 
ance of said secret-display indication. 

6. The method of claim 1 , further comprising: 

accepting at least two graphical data elements, 
each associated with a process running on said 
secured execution environment, for display on 
said display; and 

displaying at least two graphical user interface 
elements, each of said graphical user interface 
elements comprising one of said graphical data 
elements and a common graphical user inter- 
face decoration. 

7. The method of claim 6, where said common graph- 
ical user interface decoration comprises a colored 
border. 

8. The method of claim 6, where said common graph- 
ical user interface decoration comprises one or more 
randomly selected images. 

9. The method of claim 6, further comprising: 

changing said common graphical user interface 
decoration when a set time period elapses. 

10. The method of claim 6, further comprising: 

changing said common graphical user interface 
decoration when a user decoration change in- 
dication is received. 

1 1 . The method of claim 1 , wherein said first graphical 
user element comprises a window, wherein said first 
graphical user element is associated with public title 
information and private title information, wherein 
said private title information is used to identify said 
window in said secured execution environment, 
wherein said private title information is not known to 
said second execution environment, and wherein the 
method further comprises: 



providing said public title information for use by 
said second execution environment to identify 
said window. 

5 12. The method of claim 1 1 , where said second execu- 
tion environment includes a host window manager 
for managing graphical user interface elements on 
said display, where said host window manager cre- 
ates a shadow graphical user interface element for 

10 said first graphical user interface element, and where 
saidpublictitle is used by said host window manager. 

13. A computer-readable medium containing computer 
executable instructions to maintain the security of 

15 data displayed on a display for a system comprising 
a secured execution environment and a second ex- 
ecution environment, the computer-executable in- 
structions to perform acts comprising: 

20 storing an image of at least one first graphical 

user interface element associated with a first 
process running on said secured execution en- 
vironment; and 

displaying said first graphical user interface el- 
25 ement, including a first secret associated with 

said secured execution environment, on said 
display completely on a display, such that no 
part of said first graphical user interface element 
is obscured by a second graphical user interface 
30 element associated with said second execution 

environment on said display, said first secret be- 
ing communicated to said secured execution en- 
vironment by a user and not being accessible 
by a second process on said second execution 
35 environment. 

14. The computer-readable medium of claim 13, where 
said act of displaying said first graphical user inter- 
face element comprises: 

40 

ensuring that said first graphical user interface 
element contains no areas of transparency. 

15. The computer-readable medium of claim 13, where 
45 said act of displaying said first graphical user inter- 
face element on a display comprises displaying said 
first graphical user interface element such that no 
part of said first graphical user interface element is 
obscured by said second graphical user interface 

50 element, which is associated with a third process 

running on said secured execution environment. 

1 6. The computer-readable medium of claim 1 3, where- 
in the computer-executable instructions are adapted 

55 to perform acts further comprising: 

displaying only said first graphical user interface 
element on said display upon receipt of a user 
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secure display indication. 

17. The computer-readable medium of claim 13, further 
comprising: 

accepting a secret-display indication from a us- 
er; and 

displaying said first secret in response to accept- 
ance of said secret-display. 

18. The computer-readable medium of claim 13, where- 
in the computer-executable instructions are adapted 
to perform acts further comprising: 

accepting at least two graphical data elements, 
each associated with a process running on said 
secured execution environment, for display on 
said display; and 

displaying at least two graphical user interface 
elements, each of said graphical user interface 
elements comprising one of said graphical data 
elements and a common graphical user inter- 
face decoration. 

19. The computer-readable medium of claim 18, where 
said common graphical user interface decoration 
comprises a colored border. 

20. The computer-readable medium of claim 18, where 
said common graphical user interface decoration 
comprises one or more randomly selected images. 

21 . The computer-readable medium of claim 1 8, where- 
in the computer-executable instructions are adapted 
to perform acts further comprising: 

changing said common graphical user interface 
decoration when a set time period elapses. 

22. The computer-readable medium of claim 1 8, where- 
in the computer-executable instructions are adapted 
to perform acts further comprising: 

changing said common graphical user interface 
decoration when a user decoration change in- 
dication is received. 

23. The computer-readable medium of claim 1 3, where- 
in said first graphical user element comprises a win- 
dow, wherein said first graphical user element is as- 
sociated with public title information and private title 
information, wherein said private title information is 
used to identify said window in said secured execu- 
tion environment, wherein said private title informa- 
tion is not known to said second execution environ- 
ment, and wherein the acts performable by the com- 
puter-executable instructions further comprise: 



providing said public title information for use by 
said second execution environment to identify 
said window. 

5 24. The computer-readable medium of claim 23, where 
said second execution environment includes a host 
window manager for managing graphical user inter- 
face elements on said display, where said host win- 
dow manager creates a shadow graphical user in- 
fo terface element for said first graphical user interface 
element, and where said public title is used by said 
host window manager. 



15 Patentanspriiche 

1. Verfahren zum Aufrechterhalten der Sicherheit von 
Daten, die auf einer Anzeigeeinrichtung fur ein Sy- 
stem angezeigt werden, das eine gesicherte Aus- 

20 fuhrungsumgebung und eine zweite Ausfuhrungs- 
umgebung umfasst, wobei das Verfahren umfasst: 

Speichern eines Abbildes wenigstens eines er- 
sten grafischen Benutzerschnittstellenelemen- 
25 tes, das mit einem ersten Prozess zusammen- 

hangt, der in der gesicherten Ausfuhrungsum- 
gebung lauft; und 

vollstandiges Anzeigen des ersten grafischen 
Benutzerschnittstellenelementes, das ein er- 
30 stes Geheimnis enthalt, das mit der gesicherten 

Ausfuhrungsumgebung zusammenhangt, auf 
der Anzeigeeinrichtung, so dass kein Teil des 
ersten grafischen Benutzerschnittstellenele- 
mentes durch ein zweites grafischen Benutzer- 
35 schnittstellenelement, das mit der zweiten Aus- 

fuhrungsumgebung zusammenhangt, auf der 
Anzeigeeinrichtung verdeckt wird, wobei das er- 
ste Geheimnis durch einen Benutzer zu der ge- 
sicherten Ausfuhrungsumgebung ubertragen 
40 wird und fur einen zweiten Prozess in der zwei- 

ten Ausfuhrungsumgebung nichtzuganglich ist. 

2. Verfahren nach Anspruch 1, wobei der Schritt des 
Anzeigens des ersten grafischen Benutzerschnitt- 

45 stellenelementes umfasst: 



Gewahrleisten, dass das erste grafische Benut- 
zerschnittstellenelement keine Bereiche von 
Transparenz enthalt. 

50 

3. Verfahren nach Anspruch 1, wobei der Schritt des 
Anzeigens des ersten grafischen Benutzerschnitt- 
stellenelementes auf einer Anzeigeeinrichtung um- 
fasst, dass das erste grafische Benutzerschnittstel- 
55 lenelement so angezeigt wird, dass kein Teil des er- 

sten grafischen Benutzerschnittstellenelementes 
durch das zweite grafische Benutzerschnittstellen- 
element verdeckt wird, das mit einem dritten Prozess 
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zusammenhangt, der in der gesicherten Ausfuh- 
rungsumgebung lauft. 

4. Verfahren nach Anspruch 1 , das des Weiteren um- 
fasst: 

Anzeigen nur des ersten grafischen Benutzer- 
schnittstellenelementes auf der Anzeigeeinrich- 
tung beim Empfang eines Hinweises eines Be- 
nutzers auf sichere Anzeige. 



10 



11. Verfahren nach Anspruch 1, wobei das erste grafi- 
sche Benutzerelement ein Fenster umfasst, das er- 
ste grafische Benutzerelement mit offentlichen Titel- 
informationen und privaten Titelinformationen zu- 
sammenhangt, die privaten Titelinformationen dazu 
dienen, das Fenster in der gesicherten Ausfuhrungs- 
umgebung zu identifizieren, die privaten Titelinfor- 
mationen der zweiten Ausfuhrungsumgebung nicht 
bekannt sind und wobei das Verfahren des Weiteren 
umfasst: 



9. 



10. 



Verfahren nach Anspruch 1, das des Weiteren um- 
fasst: 

Annehmen eines Hinweises von einem Benut- 15 
zer auf Geheimnisanzeige, und 
Anzeigen des ersten Geheimnisses in Reaktion 
auf Annahme des Hinweises auf Geheimnisan- 
zeige. 

20 

Verfahren nach Anspruch 1, das des Weiteren um- 
fasst: 

Annehmen von wenigstens zwei grafischen Da- 
tenelementen,diejeweilsmiteinem Prozesszu- 25 
sammenhangen, der in der gesicherten Ausfuh- 
rungsumgebung lauft, zur Anzeige auf der An- 
zeigeeinrichtung; und 

Anzeigen von wenigstens zwei grafischen Be- 
nutzerschnittstellenelementen, wobei jedes der 30 
grafischen Benutzerschnittstellenelemente ei- 
nes der grafischen Datenelemente und eine ge- 
meinsame grafische Benutzerschnittstellen- 
Dekoration umfasst. 

35 

Verfahren nach Anspruch 6, wobei die gemeinsame 
grafische Benutzerschnittstellen-Dekoration einen 
gefarbten Rand umfasst. 

Verfahren nach Anspruch 6, wobei die gemeinsame 40 
grafische Benutzerschnittstellen-Dekoration ein 
oder mehr willkurlich ausgewahlte/s Bild/er umfasst. 

Verfahren nach Anspruch 6, das des Weiteren um- 
fasst: 45 

Andern dergemeinsamen grafischen Benutzer- 
schnittstellen-Dekoration, wenn ein festgelegter 
Zeitraum ablauft. 

50 

Verfahren nach Anspruch 6, das des Weiteren um- 
fasst: 

Andern dergemeinsamen grafischen Benutzer- 
schnittstellen-Dekoration, wenn ein Hinweis ei- 55 
nes Benutzer auf Anderung der Dekoration 
empfangen wird. 



Bereitstellen der offentlichen Titelinformationen 
zur Verwendung durch die zweite Ausfuhrungs- 
umgebung zum Identifizieren des Fensters. 

12. Verfahren nach Anspruch 1 1 , wobei die zweite Aus- 
fuhrungsumgebung einen Host-Fenster-Manager 
zum Verwalten grafischer Benutzerschnittstellen- 
elemente auf der Anzeigeeinrichtung enthalt, der 
Host-Fenster-Manager ein schattiertes grafisches 
Benutzerschnittstellenelement fur das erste grafi- 
sche Benutzerschnittstellenelement erzeugt und der 
offentliche Titel von dem Host-Fenster-Manager ver- 
wendet wird. 

13. Computerlesbares Medium, das durch Computer 
ausfuhrbare Befehle zum Aufrechterhalten der Si- 
cherheit von Daten enthalt, die auf einer Anzeige- 
einrichtung fur ein System angezeigt werden, das 
eine gesicherte Ausfuhrungsumgebung und eine 
zweite Ausfuhrungsumgebung umfasst, wobei die 
durch Computer ausfuhrbaren Befehle dazu dienen, 
Vorgange durchzufuhren, die umfassen: 

Speichern eines Abbildes wenigstens eines er- 
sten grafischen Benutzerschnittstellenelemen- 
tes, das mit einem ersten Prozess zusammen- 
hangt, der in der gesicherten Ausfuhrungsum- 
gebung lauft; und 

vollstandiges Anzeigen des ersten grafischen 
Benutzerschnittstellenelementes, das ein er- 
stes Geheimnis enthalt, das mit der gesicherten 
Ausfuhrungsumgebung zusammenhangt, auf 
der Anzeigeeinrichtung, so dass kein Teil des 
ersten grafischen Benutzerschnittstellenele- 
mentes durch ein zweites grafisches Benutzer- 
schnittstellenelement, das mit der zweiten Aus- 
fuhrungsumgebung zusammenhangt, auf der 
Anzeigeeinrichtung verdeckt wird, wobei das er- 
ste Geheimnis durch einen Benutzer zu der ge- 
sicherten Ausfuhrungsumgebung ubertragen 
wird und fur einen zweiten Prozess in der zwei- 
ten Ausfuhrungsumgebung nicht zuganglich ist. 

14. Computerlesbares Medium nach Anspruch 13, wo- 
bei der Vorgang des Anzeigens des ersten grafi- 
schen Benutzerschnittstellenelementes umfasst: 
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Gewahrleisten, dass das erste grafische Benut- 
zerschnittstellenelement keine Bereiche von 
Transparenz enthalt. 

15. Computerlesbares Medium nach Anspruch 13, wo- 
bei der Vorgang des Anzeigens des ersten grafi- 
schen Benutzerschnittstellenelementes auf einer 
Anzeigeeinrichtung umfasst, dass das erste grafi- 
sche Benutzerschnittstellenelement so angezeigt 
wird, dass kein Teil des ersten grafischen Benutzer- 
schnittstellenelementes durch das zweite grafische 
Benutzerschnittstellenelement verdeckt wird, das 
mit einem dritten Prozess zusammenhangt, der in 
der gesicherten Ausfuhrungsumgebung lauft. 

16. Computerlesbares Medium nach Anspruch 13, wo- 
bei die durch Computer ausfuhrbaren Befehle zum 
Durchfuhren von Vorgangen eingerichtet sind, die 
des Weiteren umfassen: 

Anzeigen nur des ersten grafischen Benutzer- 
schnittstellenelementes auf der Anzeigeeinrich- 
tung beim Empfang eines Hinweises eines Be- 
nutzers auf sichere Anzeige. 

17. Computerlesbares Medium nach Anspruch 13, das 
des Weiteren umfasst: 

Annehmen eines Hinweises von einem Benut- 
zer auf Geheimnisanzeige; und 
Anzeigen des ersten Geheimnisses in Reaktion 
auf Annahme der Geheimnisanzeige. 

18. Computerlesbares Medium nach Anspruch 13, wo- 
bei die durch Computer ausfuhrbaren Befehle zum 
Durchfuhren von Vorgangen eingerichtet sind, die 
des Weiteren umfassen: 

Annehmen von wenigstens zwei grafischen Da- 
tenelementen, die jeweils mit einem Prozess zu- 
sammenhangen, der in der gesicherten Ausfuh- 
rungsumgebung lauft, zur Anzeige auf der An- 
zeigeeinrichtung; und 

Anzeigen von wenigstens zwei grafischen Be- 
nutzerschnittstellenelementen, wobei jedes der 
grafischen Benutzerschnittstellenelemente ei- 
nes der grafischen Datenelemente und eine ge- 
meinsame grafische Benutzerschnittstellen- 
Dekoration umfasst. 

19. Computerlesbares Medium nach Anspruch 18, wo- 
bei die gemeinsame grafische Benutzerschnittstel- 
len-Dekoration einen farbigen Rand umfasst. 

20. Computerlesbares Medium nach Anspruch 18, wo- 
bei die gemeinsame grafische Benutzerschnittstel- 
len-Dekoration ein oder mehr willkurlich ausgewahl- 
te/s Bild/er umfasst. 



21. Computerlesbares Medium nach Anspruch 18, wo- 
bei die durch Computer ausfuhrbaren Befehle zum 
Durchfuhren von Vorgangen eingerichtet sind, die 
des Weiteren umfassen: 

5 

Andern der gemeinsamen grafischen Benutzer- 
schnittstellen-Dekoration, wenn ein festgelegter 
Zeitraum ablauft. 

10 22. Computerlesbares Medium nach Anspruch 18, wo- 
bei die durch Computer ausfuhrbaren Befehle zum 
Durchfuhren von Vorgangen eingerichtet sind, die 
des Weiteren umfassen: 

15 Andern der gemeinsamen grafischen Benutzer- 

schnittstellen-Dekoration, wenn ein Hinweis ei- 
nes Benutzers auf Anderung der Dekoration 
empfangen wird. 

20 23. Computerlesbares Medium nach Anspruch 13, wo- 
bei das erste grafische Benutzerelement ein Fenster 
umfasst, das erste grafische Benutzerelement mit 
offentlichen Titelinformationen und privaten Titelin- 
formationen zusammenhangt, die privaten Titelin- 
25 formationen dazu dienen, das Fenster in der gesi- 
cherten Ausfuhrungsumgebung zu identifizieren, die 
privaten Titelinformationen der zweiten Ausfuh- 
rungsumgebung nicht bekannt sind, und wobei die 
durch die Computer ausfuhrbaren Befehlen durch- 
30 fuhrbaren Vorgange des Weiteren umfassen: 

Bereitstellen der offentlichen Titelinformationen 
zur Verwendung durch die zweite Ausfuhrungs- 
umgebung zum Identifizieren des Fensters. 

35 

24. Computerlesbares Medium nach Anspruch 23, wo- 
bei die zweite Ausfuhrungsumgebung einen Host- 
Fenster-Manager zum Verwalten grafischer Benut- 
zerschnittstellenelemente auf der Anzeigeeinrich- 
40 tung enthalt, der Host- Fenster- Manager ein schat- 
tiertes grafisches Benutzerschnittstellenelement fur 
das erste grafische Benutzerschnittstellenelement 
erzeugt und der offentliche Titel von dem Host-Fen- 
ster-Manager verwendet wird. 



Revendications 

1 . Procede pour maintenir la securite de donnees affi- 
chees sur un dispositif d'affichage pour un systeme 
comportant un environnement d'execution securise 
et un second environnement d'execution, 
comprenant : 

le stockage d'une image d'au moins un premier 
element d'interface graphique utilisateur asso- 
cie a un premier processus execute dans ledit 
environnement d'execution securise ; et 



25 



55 



12 



23 



EP 1 526 424 B1 



24 



I'affichage dudit premier element d'interface 
graphique utilisateur qui comprend un premier 
secret associe audit environnement d'execution 
securise, sur ledit dispositif d'affichage entiere- 
ment sur un ecran, de facon qu'aucune partie 
dudit premier element d'interface graphique uti- 
lisateur ne soit cachee par un second element 
d'interface graphique utilisateur associe audit 
second environnementd'execution sur ledit dis- 
positif d'affichage, ledit premier secret etant 
communique audit environnement d'execution 
securise par un utilisateur et n'etant pas acces- 
sible par un second processus execute dans le- 
dit second environnement d'execution. 

2. Procede selon la revendication 1 , dans lequel ladite 
etape d'affichage dudit premier element d'interface 
graphique utilisateur comprend : 

le faitde faire en sorte que ledit premier element 
d'interface graphique utilisateur ne contienne 
aucune zone de transparence. 

3. Procede selon la revendication 1 , dans lequel ladite 
etape d'affichage dudit premier element d'interface 
graphique utilisateur sur un dispositif d'affichage 
comprend I'affichage dudit premier element d'inter- 
face graphique utilisateur de facon qu'aucune partie 
decedernierne soit cachee par leditsecond element 
d'interface graphique utilisateur qui est associe a un 
troisieme processus execute dans ledit environne- 
ment d'execution securise. 

4. Procede selon la revendication 1, comprenant 
egalement : 

I'affichage uniquement dudit premier element 
d'interface graphique utilisateur sur ledit dispo- 
sitif d'affichage lors de la reception d'une indi- 
cation d'affichage securise d'utilisateur. 

5. Procede selon la revendication 1, comprenant 
egalement : 

I'acceptation d'une indication d'affichage de se- 
cret provenant d'un utilisateur ; et 
I'affichage dudit premier secret en reponse a 
I'acceptation de ladite indication d'affichage de 
secret. 

6. Procede selon la revendication 1, comprenant 
egalement : 

I'acceptation d'au moins deux elements de don- 
nees graphiques respectivement associes a un 
processus execute dans ledit environnement 
d'execution securise, en vue de leur affichage 
sur ledit dispositif d'affichage ; et 



I'affichage d'au moins deux elements d'interface 
graphique utilisateur, chacun desdits elements 
d'interface graphique utilisateur comprenant 
I'un desdits elements de donnees graphiques et 
5 une decoration d'interface graphique utilisateur 

commune. 

7. Procede selon la revendication 6, dans lequel ladite 
decoration d'interface graphique utilisateur commu- 

10 ne comprend une bordure coloree. 

8. Procede selon la revendication 6, dans lequel ladite 
decoration d'interface graphique utilisateur commu- 
necomprenduneou plusieurs images selectionnees 

15 de maniere aleatoire. 

9. Procede selon la revendication 6, comprenant 
egalement : 

20 |e changement de ladite decoration d'interface 

graphique utilisateur commune lorsqu'une pe- 
riode de temps definie s'est ecoulee. 

10. Procede selon la revendication 6, comprenant 
25 egalement : 

le changement de ladite decoration d'interface 
graphique utilisateur commune lorsqu'une indi- 
cation de changement de decoration d'utilisa- 
30 teur est recue. 

11. Procede selon la revendication 1, dans lequel ledit 
premier element d'interface graphique utilisateur 
comprend une fenetre, ledit premier element d'inter- 

35 face graphique utilisateur etant associe a des infor- 
mations de libelle public et a des informations de 
libelle prive, dans lequel lesdites informations de li- 
belle prive sont utilisees pour identifier ladite fenetre 
dans ledit environnementd'execution securise, dans 

40 lequel lesdites informations de libelle prive ne sont 
pas connues dudit second environnement d'execu- 
tion, et dans lequel le procede comprend 
egalement : 

45 la fourniture desdites informations de libelle pu- 

blic pourqu'ellessoientutilisees par leditsecond 
environnementd'execution afin d'identifier ladi- 
te fenetre. 

50 12. Procede selon la revendication 1 1 , dans lequel ledit 
second environnement d'execution comprend un 
gestionnaire de fenetre hote pour gerer des ele- 
ments d'interface graphique utilisateur sur ledit dis- 
positif d'affichage, dans lequel ledit gestionnaire de 

55 fenetre hote cree un element d'interface graphique 
utilisateur avec un effet d'ombre pour ledit premier 
element d'interface graphique utilisateur, et dans le- 
quel ledit libelle public est utilise par ledit gestionnai- 
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re de fenetre hote. 

13. Support lisible par ordinateur contenant des instruc- 
tions executables par ordinateur pour maintenir la 
securite de donnees affichees sur un dispositif d'af- 
fichage pour un systeme comportant un environne- 
ment d'execution securise et un second environne- 
ment d'execution, les instructions executables par 
ordinateur etant adaptees pour realiser des opera- 
tions comprenant : 

le stockage d'une image d'au moins un premier 
element d'interface graphique utilisateur asso- 
cie a un premier processus execute dans ledit 
environnement d'execution securise ; et 
I'affichage dudit premier element d'interface 
graphique utilisateur qui comprend un premier 
secret associe audit environnement d'execution 
securise, sur ledit dispositif d'affichage entiere- 
ment sur un ecran, de facon qu'aucune partie 
dudit premier element d'interface graphique uti- 
lisateur ne soit cachee par un second element 
d'interface graphique utilisateur associe audit 
second environnement d'execution sur ledit dis- 
positif d'affichage, ledit premier secret etant 
communique audit environnement d'execution 
securise par un utilisateur et n'etant pas acces- 
sible par un second processus execute dans le- 
dit second environnement d'execution. 

14. Support lisible par ordinateur selon la revendication 
1 3, dans lequel ladite operation d'affichage dudit pre- 
mier element d'interface graphique utilisateur 
comprend : 

le faitde faire en sorte que ledit premier element 
d'interface graphique utilisateur ne contienne 
aucune zone de transparence. 

15. Support lisible par ordinateur selon la revendication 
1 3, dans lequel ladite operation d'affichage dudit pre- 
mier element d'interface graphique utilisateur sur un 
dispositif d'affichage comprend I'affichage dudit pre- 
mier element d'interface graphique utilisateur de fa- 
con qu'aucune partie de ce dernier ne soit cachee 
par ledit second element d'interface graphique utili- 
sateur qui est associe a un troisieme processus exe- 
cute dans ledit environnement d'execution securise. 

16. Support lisible par ordinateur selon la revendication 
13, dans lequel les instructions executables par or- 
dinateur sont adaptees pour realiser des operations 
comprenant egalement : 

I'affichage uniquement dudit premier element 
d'interface graphique utilisateur sur ledit dispo- 
sitif d'affichage lors de la reception d'une indi- 
cation d'affichage securise d'utilisateur. 



17. Support lisible par ordinateur selon la revendication 
13, comprenant egalement : 

I'acceptation d'une indication d'affichage de se- 
5 cret provenant d'un utilisateur ; et 

I'affichage dudit premier secret en reponse a 
I'acceptation dudit affichage de secret. 

18. Support lisible par ordinateur selon la revendication 
10 13, dans lequel les instructions executables par or- 
dinateur sont adaptees pour realiser des operations 
comprenant egalement : 

I'acceptation d'au moins deux elements de don- 
15 nees graphiques respectivement associes a un 

processus execute dans ledit environnement 
d'execution securise, en vue de leur affichage 
sur ledit dispositif d'affichage ; et 
I'affichage d'au moins deux elements d'interface 
20 graphique utilisateur, chacun desdits elements 

d'interface graphique utilisateur comprenant 
I'un desdits elements de donnees graphiques et 
une decoration d'interface graphique utilisateur 
commune. 

25 

1 9. Support lisible par ordinateur selon la revendication 
1 8, dans lequel ladite decoration d'interface graphi- 
que utilisateur commune comprend une bordure co- 
loree. 

30 

20. Support lisible par ordinateur selon la revendication 
18, dans lequel ladite decoration d'interface graphi- 
que utilisateur commune comprend une ou plusieurs 
images selectionnees de maniere aleatoire. 

35 

21 . Support lisible par ordinateur selon la revendication 
18, dans lequel les instructions executables par or- 
dinateur sont adaptees pour realiser des operations 
comprenant egalement : 

40 

le changement de ladite decoration d'interface 
graphique utilisateur commune lorsqu'une pe- 
riode de temps definie s'est ecoulee. 

45 22. Support lisible par ordinateur selon la revendication 
18, dans lequel les instructions executables par or- 
dinateur sont adaptees pour realiser des operations 
comprenant egalement : 

50 le changement de ladite decoration d'interface 

graphique utilisateur commune lorsqu'une indi- 
cation de changement de decoration d'utilisa- 
teur est recue. 

55 23. Support lisible par ordinateur selon la revendication 
13, dans lequel leditpremier elementd'interface gra- 
phique utilisateur comprend une fenetre, ledit pre- 
mier element d'interface graphique utilisateur etant 
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associe a des informations de libelle public et a des 
informations de libelle prive, dans lequel lesdites in- 
formations de libelle prive sont utilisees pour identi- 
fier ladite fenetre dans ledit environnement d'execu- 
tion securise, dans lequel lesdites informations de 5 
libelle prive ne sont pas connues dudit second envi- 
ronnement d'execution, et dans lequel les opera- 
tions realisables par les instructions executables par 
ordinateur comprennent egalement : 

10 

la fourniture desdites informations de libelle pu- 
blic pour qu'ellessoient utilisees par ledit second 
environnement d'execution afin d'identifier ladi- 
te fenetre. 

15 

24. Support lisible par ordinateur selon la revendication 
23, dans lequel ledit second environnement d'exe- 
cution comprend un gestionnaire de fenetre note 
pour gerer des elements d'interface graphique utili- 
sateur sur ledit dispositif d'affichage, dans lequel le- 20 
dit gestionnaire de fenetre hote creeun elementd'in- 
terface graphique utilisateur avec un effet d'ombre 
pour ledit premier element d'interface graphique uti- 
lisateur, et dans lequel ledit libelle public est utilise 
par ledit gestionnaire de fenetre hote. 25 
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